package mysql8学习.高级.第09章_性能分析工具;

/**
 * 在数据库调优中，我们的目标就是响应时间更快，吞吐量更大。
 * 利用宏观的监控工具和微观的日志分析可以帮我们快速找到调优的思路和方式。
 *
 * 当我们遇到数据库调优问题的时候，该如何思考呢?
 *      这里把思考的流程整理成下面这张图。
 * 整个流程划分成了观察(Show status) 和行动(Action)两个部分。
 * 字母S的部分代表观察(会使用相应的分析工具)，
 * 字母A代表的部分是行动(对应分析可以采取的行动) .
 *  详见
 *  ---A_数据库调优流程图.png---
 *
 *  我们可以通过观察了解数据库整体的运行状态，
 *  通过性能分析工具可以让我们了解执行慢的SQL都有哪些，
 *  查看具体的SQL执行计划.甚至是sQL执行中的每一步的成本代价，
 *  这样才能定位问题所在，找到了问题，再采取相应的行动。
 *
 *  详细解释一下这张图:
 * ●  首先在S1部分，我们需要观察服务器的状态是否存在周期性的波动。
 * 如果存在周期性波动，有可能是周期性节点的原因,比如双十一、促销活动等。
 * 这样的话，我们可以通过A1这一步骤解决,也就是加缓存，或
 * 者更改缓存失效策略。
 *
 * ●  如果缓存策略没有解决，或者不是周期性波动的原因，
 *  我们就需要进一步分析查询延退和卡顿的原因。
 *  接下来进入S2这一步,我们需要开启慢查询。
 *  慢查询可以帮我们定位执行慢的sQL语句。
 *  我们可以通过设置
 *  long_query_time参数定义“慢”的阈值，
 *  如果SQL执行时间超过了long_query_time,则会认为是慢查询。
 *  当收集上来这些慢查询之后，我们就可以通过分析工具对慢查询日志进行分析。
 * ●  在S3这一步骤中，我们就知道了执行慢的SQL,
 *  这样就可以针对性地用EXPLAIN查看对应SQL语句的执行计划，
 *  或者使用 show profile 查看SQL中每一个步骤的时间成本。
 *  这样我们就可以了解SQL查询慢是因为执行时间长，还是等待时间长。
 * ●  如果是SQL等待时间长，我们进入A2步骤。
 * 在这一步骤中,我们可以调优服务器的参数，比如适当增加数据库缓冲池等。
 * 如果是SQL执行时间长，就进入A3步骤，
 * 这一步中我们需要考虑是   索引设计的问题? 还是查询关联的数据表过多?
 * 还是因为数据表的字段设计问题导致了这一现象。
 * 然后在这些维度上进行对应的调整。
 * ●  如果A2和A3都不能解决问题，我们需要考虑数据库自身的SQL查询性能是否已经达到了瓶颈，
 * 如果确认没有达到性能瓶颈，就需要重新检查，夏以上的步骤。
 * 如果已经达到了性能瓶颂，进入A4阶段，需要考虑增加服务器。
 * 采用读写分离的架构，或者考虑对数据库进行分库分表，
 * 比如垂直分库、垂直分表和水平分表等。
 * 以上就是数据库调优的流程思路。
 * 如果我们发现执行SQL时存在不规则延迟或卡顿的时候，
 * 就可以采用分析工具帮我们定位有问题的SQL,
 * 这三种分析工具你可以理解是SQL调优的三个步骤:
 *      慢查询、 EXPLAIN 和 SHOW PROFILING。
 *
 * 小结：
 *
 *  硬件  -> 系统配置 ->   数据库表设计  -> SQL及索引
 *  成本由高到低
 *  效果由低到高
 *  所以  好的索引有很大优点
 */
public class A_数据库服务器优化 {
}
